fix(webrtc): reduce PeerConnectionAnalyzer log verbosity during bad quality#18418
fix(webrtc): reduce PeerConnectionAnalyzer log verbosity during bad quality#18418pallavibakale wants to merge 3 commits into
Conversation
…uality Signed-off-by: pallavibakale <pallavibakale09@gmail.com>
nickvergessen
added
bug
feature: frontend 🖌️
|
Hello there, We hope that the review process is going smooth and is helpful for you. We want to ensure your pull request is reviewed to your satisfaction. If you have a moment, our community management team would very much appreciate your feedback on your experience with this PR review process. Your feedback is valuable to us as we continuously strive to improve our community developer experience. Please take a moment to complete our short survey by clicking on the following link: https://cloud.nextcloud.com/apps/forms/s/i9Ago4EQRZ7TWxjfmeEpPkf6 Thank you for contributing to Nextcloud and we hope to hear from you soon! (If you believe you should not receive this message, you can add yourself to the blocklist.) |
This is a preparation to test passing different parameters. Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
danxuliu
left a comment
danxuliu
left a comment
There was a problem hiding this comment.
Sorry for the delay and thanks for your contribution!
I left some review comments and took the freedom to add some unit tests to verify the new parameters of _logRtcStats.
Independently of all that I noticed that, sometimes, all the RTC stats are logged even if the connection did not improve since the last log. However, I am not sure if the problem is in how the RTC stats are logged or if there is a problem in the quality calculation (like a good quality being suddenly reported between two very bad reports) 🤔
| this._timestampsForLogs[kind].reset() | ||
|
|
||
| this._totalRtcStatsAdded[kind] = 0 | ||
| this._loggedUpToRtcStatsTotal[kind] = -1 |
There was a problem hiding this comment.
This should not be necessary (but I am not fully sure 🤔). Although the data to calculate the quality is reset, the RTC stats array is never reset, so the total count of RTC stats and the last logged RTC stat would still be valid and independent of the data to calculate the quality.
| console.debug('%s: Timestamps: %s', tag, this._timestampsForLogs[kind].toString()) | ||
|
|
||
| this._logRtcStats(tag, kind) | ||
| const startTotal = logAll ? 0 : this._loggedUpToRtcStatsTotal[kind] |
There was a problem hiding this comment.
When the full RTC stats are logged they will always be indexed at 0. However, subsequent logs will take into account the total count of RTC stats, so the value will jump to something higher. Therefore the initial log should also respect the total count of RTC stats (probably something like logAll ? this._totalRtcStatsAdded[kind] - newcount : this._loggedUpToRtcStatsTotal[kind], although I have not checked it).
3 participants
☑️ Resolves
🛠️ API Checklist
🚧 Tasks
When connection quality is bad,
_logStatswas called every second and logged the full 5-7 entry rtcStats history each time, causing heavy duplication in the logs.Now only the new rtcStats entries (added since the last log) are printed on each subsequent bad check. When quality recovers, any remaining unlogged entries are flushed once so no data is missing.
🏁 Checklist
docs/has been updated or is not required